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Abstract 


Symbolics Genera was the world's first commercial 
object-oriented operating system. This paper describes a 
few interesting aspects of Genera, recounts some 
experience, and offers advice to designers of future object- 
oriented systems. 


Introduction 


Symbolics Genera was the world's first commercial 
object-oriented operating system and is still alive today. 
Object-oriented programming is used in many ways 
throughout Genera, some more successful than others. 
The purpose of this paper is not to provide a complete 
description of Genera (see [1, 2]), but to touch on a few 
points of particular interest and draw some lessons for 
designers of future object-oriented systems. 

This paper presents my own personal view. It might 
not accurately depict the nature or history of any 
Symbolics product. All trademarks mentioned in this 
paper are the property of their owners. 

A brief description of Genera's purpose and history is 
necessary as background information: 

Genera is the operating software for Symbolics 
computers, comprising three lines of workstations plus 
embedded coprocessors for SUN workstations and 
Macintosh personal computers. The coprocessors run 
workstation-style software, borrowing the I/O devices and 
user interfaces of the host computer. 

Genera is a comprehensive set of software, comprising 
the operating system, user interface toolbox, utilities, 
language runtime systems, and development tools such as 
editor, compiler, debugger, performance metering tools, 
etc. The Genera software environment is a single-user 
workstation, with multiple processes in one address 
space, using preemptive scheduling. It is heavily 
oriented towards networks, graphical user interface, and 
rapid program development. The main language is Lisp 
(5 dialects are supported, all related to Common Lisp). 
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All of Genera is written in Lisp. Very low-level code, 
such as the virtual memory system, is written in a subset 
of Lisp without automatic storage management. Genera 
also supports Fortran, Pascal, and C; Ada and Prolog 
have been discontinued, The Joshua [3] AI language is 
available; it exploits object technology and protocols to 
give very high performance for rule-based programs. 

Applications of Genera fall into two categories: (1) 
Exploratory programming: An expert can produce an 
impressive prototype of an application in just a few 
hours. Often a consultant will “jump-start” a project by 
building a prototype for the customer to finish over the 
next few months. (2) Industrial deployment of very 
complex, high-payback applications such as operational 
scheduling, intelligent CAD, and graphics. Genera is not 
cost-effective for delivery of simple or routine 
applications, but it shines in “production transaction- 
oriented applications, where expert systems, 
heterogeneous network communication, database access, 
and a lot of traditional data-processing-like code need to 
be developed quickly, be thoroughly integrated, and track 
a complex and and/or quickly changing external 
environment.” [4] 


History 


The Lisp Machine project at M.I.T. [5] began in 1974 
with the concept of creating networked, single-user 
workstations with graphical user interfaces. Replacing 
the time-shared pdp-10 system A.J. Lab researchers were 
using at the time would deliver a great increase in power 
and responsiveness, but retain most of the benefits of 
time-sharing by sharing central resources such as printers, 
file servers, and chess processors via the network. This 
was conscious imitation of the successes that Kerox 
PARC was achieving with the Alto. However, the Lisp 
Machine would focus on providing a good 
implementation of the pdp-10 Maclisp language that the 
researchers were currently using. In addition, a 32-bit 
architecture would be used, since the Alto'’s 16-bit 
architecture had caused many problems and limitations. 


M.LT. developed two generations of hardware and by 
1979 more than a dozen prototype machines were in daily 
use around the school. The software had greatly 
outstripped the original vision of reimplementing pdp-10 
Maclisp; removal of the memory size,processor speed, 
display bandwidth, and response-time constraints of the 
time-shared system led to a tremendous explosion of new 
software ideas. At the same time, object-oriented 
programming was becoming a well-known idea; several 
different object-oriented language experiments were tried 
within the Lisp Machine system. At this stage there 
weren't enough users—or they didn't have aggressive 
enough personalities—for compatibility to be a 
significant constraint. Experimentation and rapid 
development in all directions were the order of the day. 

M.LT. licensed the Lisp Machine technology to two 
Startup companies, Symbolics inc. and Lisp Machines 
inc., and later to Texas Instruments, so it could be 
developed and manufactured commercially. Symbolics' 
software product that evolved from this technology was 
called Genera. The startup companies did not become the 
next Digital Equipment Corp., but Lisp Machine 
technology has had a big impact within its niche of 
complex applications and rapid prototyping. 


An open system 


Most operating systems, such as Unix, have a 
supervisor/user structure, with the supervisor protected 
from the user by hardware. It's fashionable to call the 
supervisor a kernel, especially when it's small. This 
structure reflects the social arrangements of mainframe 
computers (all computers in the early 1960s when this 
style of operating system was conceived), where the 
computer is protected behind glass and only touched by 
specialists, not by users. 

Genera, like the personal computer operating systems, 
has a truly open structure in which no firm distinction is 
drawn between user programs and system programs, A 
user program can access or modify any part of the system 
that it can find. There is no real kernel, unless you call 
the software that boots the machine a kernel. Unlike the 
PC systems, Genera is organized as a sea of (potentially) 
interacting objects. This reflects the social arrangements 
of desktop computers, where the individual totally 
controls the computer. 

The advantage of an open system is that the 
application programmer is in control and can get the 
system to do anything deemed necessary. This 
malleability eases rapid prototyping. There are also 
efficiency advantages: putting everything in a single 
address space is cheaper than multiple address spaces, 
because context switching is faster and page tables take 
less space. Using ordinary lightweight objects for 


system objects and ordinary calls for system invocation 
speeds up the interface between the application and the 
system. 

Users report that Genera's policy of shipping most of 
the source code and everything needed to compile it is a 
big help. This is another form of openness that provides 
lots of working examples as well as a fallback when 
documentation is incomplete or when an extension is 
necessary that was not anticipated in the system design, 
such as an entirely new user interface. Perhaps a truly 
perfect implementation of object-oriented extensibility 
could eliminate the need to consult source code. 

There are certain disadvantages to an open system. 
The one that usually tops the list is insecurity. Without 
a protected kernel, the computer can't be secure from 
meddling by unauthorized users. While this is true, any 
computer that allows user access to the facilities for 
installing new software is inherently insecure no matter 
how its operating system is structured. In this sense, 
Genera and Sun Unix have the same level of security; 
anyone with physical access to the machine who knows 
the right incantation can break security, and the 
incantation is widely known within the user community. 
True security can only by achieved either by locking up 
the computer, as with mainframes, or by putting the 
entire computer outside the security perimeter and 
managing the network in a security-conscious fashion, 
as Genera and personal computers do. 

Another feared disadvantage is that a buggy application 
will clobber something and crash the wholé system. 
This has not been a serious problem in Genera; see the 
“Object-oriented memory” section. 

A real disadvantage of open systems is that there is no 
enforcement of modularity. If a programmer tries to call 
an internal entry point that is not supposed to be called, 
there is no wall of protection to prevent this. Some parts 
of Genera have well-documented interfaces and take 
advantage of Common Lisp packages to remind the user 
which entry points are exported and which are not; these 
parts have not had much trouble with inappropriate 
exploitation of openness. Other parts of Genera have 
poorly-documented interfaces, and, even worse, have 
incomplete interfaces so that programmers must call 
internal entry points to do their work; these parts have 
been constantly plagued with compatibility and 
modularity problems. The lesson seems to be that well- 
defined, well-designed, and complete interfaces are 
important, regardless of whether they are enforced or 
merely guidelines to suggested good style. 


Object system 


The object systems in Genera are CLOS {6] and its 
close ancestor Flavors [7, 8]. These object systems are 


based on classes and instances, rather than prototypes, and 
on generic functions rather than messages. They use 
multiple inheritance. Objects are high-speed, 
lightweight, non-distributed, and non-persistent. Storage 
for unused objects is reclaimed automatically by garbage 
collection. No distinction is made between “system 
objects” and “language objects.” 

Genera is a multi-process system but objects are 
below the process level. Objects are passive; there is not 
a separate process for each object. Synchronization is 
separate from both object invocation and function 
invocation. 

Genera and its development system, in the 
configuration I use, contain roughly 4000 classes, 13,000 
generic functions, 19,000 methods, and 61,000 instances 
of 2500 classes. Only 45 classes have more than 100 
instances; the most popular class is associated with on- 
line documentation. The instance count was taken 
immediately after booting and then collecting garbage. It 
ignores instances of what CLOS calls built-in classes. 
Loading more applications or more network types would 
increase these numbers. 1/3 of all classes directly use 
multiple inheritance. 


Object-oriented memory 


In Genera, everything in memory is an object; there 
are no “raw bits.” Of course there are bit and byte arrays, 
which provide the equivalent functionality of raw 
unstructured memory found in other systems, but 
encapsulated inside an object. Object-oriented memory 
does not mean that the LOAD and STORE instructions are 
generic and do different things on different memory 
locations, it just means that memory is structured into 
objects. Given any memory address, the starting address, 
size, and type of the object that contains that location can 
be determined. All parts of the software obey this 
convention. 

An object is referenced by its address plus six tag bits. 
There are three representations for objects: Small objects 
(such as cons pairs) consist of just their fields, with no 
overhead; their type is encoded in their address. Large 


objects consist of a header word that describes the object's, 


type and size, followed by as much memory as necessary 
to represent the object (e.g. one word per slot fora CLOS 
instance). Certain small, immutable objects (e.g. 
numbers, characters) are represented entirely within 
references to them and occupy no memory. 

The basic primitives into which programs are 
compiled are object-style primitives, implemented by a 
combination of hardware and microcode, that do run-time 
type checking, garbage collection checking, and array 
bounds checking. Raw LOAD and STORE operations do 
exist but are rarely used. 


The structure of Genera objects in memory is unlike 
most Smalltalk implementations, where objects are 
referenced indirectly through an Object Table; unlike 
most C++ implementations, where the type and size of 
an object cannot always be determined given only its 
address; and unlike distributed-object systems and 
capability systems, where the storage of an object resides 
in memory that cannot be accessed. Genera emphasizes 
lightweight objects. For further information, see [9]. 

The original Lisp Machine architecture implemented 
object-oriented memory without full tagging. Some 
memory locations contained tags, others contained just 
32 “raw” bits. The introduction of tag bits on every 
memory word in 1983 significantly simplified the 
implementation, and as a result significantly improved 
performance. To see how this happened, think about a 
program (such as the garbage collector) trying to examine 
a single memory word in isolation. In a fully tagged 
architecture, no contextual information is required to 
“understand” the contents of a word; all memory words 
use their bits the same way. In other architectures, some 
memory words contain addresses, others contain bit 
pattems or numbers. The difference can only be discerned 
by consulting descriptive information elsewhere in 
memory. 

Full tagging doesn't make anything possible that was 
totally impossible before, but it does simplify things. 
For example, when the virtual memory system removes a 
page from main memory, the garbage collector gets a 
chance to examine that page and determine whether there 
is any reason to bring it back into memory when the next 
garbage collection occurs. If not, the overhead of a later 
page fault is avoided [10]. The fully tagged architecture 
makes it possible to do this without consulting 
information stored on any other pages, and thus without 
the risk of taking a page fault inside the virtual memory 
system at an inconvenient time. 

Because of object-oriented memory, “random 
clobbering” of one application by another, or of the 
system by an application, or of an application by itself, 
is rarely experienced in practice. This not only lessens 
significantly the need for hardware memory protection, 
but eliminates the unreproducible errors with “insane” 
symptoms that plague developers on “raw bits” systems. 
No doubt the fact that the basic primitives do run-time 
checking helps in achieving this robustness. 


Generic file access 


Genera was designed to work in a networked 
environment containing diverse file servers based on 
different operating systems, offering different filing 
features, and communicating through different protocols. 
(The word “protocol” is used here in a network sense, not 


in the object sense used in most of this paper, defined in 
the “Software engineering” section.) The designers of 
Genera considered it unacceptable for the user to have to 
wade through network complexity just to get to a file. 
Thus Genera uses a generic file access model that 
conceals the differences among file systems as much as 
possible. The user accesses files on the local disk and 
files on an Internet server on the other side of the planet 
using exactly the same commands and application 
program interface (the local files are likely to be faster). 
Users just name files, they never explicitly invoke 
programs such as FTP. It's up to the system to navigate 
automatically through the available protocols and 
networks, 

Genera was the first system to emphasize open, 
heterogeneous networking. The strategy is quite different 
from other approaches such as NFS and Appleshare File 
Protocol; Genera adapts to the models native to server 
hosts, instead of requiring them to emulate Genera's own 
file system. The generic file model could have been a 
least-common-denominator model, containing only 
features that every file system in the world implements. 
The problem with this is that such a model would be so 
weak that users would have a strong motivation to 
bypass the generic interface in order to get the richer 
features of a particular server. Instead, the generic file 
model is a rich model with mechanisms for graceful 
degradation when not all features exist in a particular file 
system. In general it's oriented more towards sequential 
stream access than random access and record-structured 
files. 

The important objects of the generic file model are 
pathnames, file access paths, and streams. 

A pathname is an object that names a file; its class 
depends on the type of file server. A pathname comprises 
the name of a file server, a colon, and file-system- 
dependent syntax for the file name, directory, and so 
forth. The application program interface includes file- 
system-independent operations so programs can 
manipulate pathnames without requiring special 
programming for each file name syntax. A generic 
syntax after the colon was considered, so users wouldn't 
have to know the syntax of particular servers either, but 
it was found more useful to support each file server's 
native syntax. This allows Genera users and native users 
of a server to communicate easily. 

A file access path represents a particular network 
connection to a particular file server, using a particular 
network protocol. The class of the object depends on the 
protocol. In some cases it also depends on the type of 
file server, especially when protocol standards are loosely 
enforced and some file servers require special 
programming to work around bugs in their 
implementation of the protocol. 


A stream represents a file open through a file access 
path. The class of a stream depends on the mode of 
access to the file. It usually also depends on the class of 
the file access path, to cut down on the number of 
method invocations needed to do I/O, by minimizing 
delegation from the stream to the file access path. 

Genera supports many file systems and file access 
protocols. Nineteen file system types are supported, such 
as ISO 9660 CD-ROMs, two versions of Unix, three 
versions of VAX/VMS, two kinds of personal computer, 
a “random” type that gives minimal functionality on any 
file system, etc. Seven protocols are supported: direct 
calls to a local file system, Internet's TCP-FTP and 
TFTP, SUN's NFS, Digital's DAP, MIT's QFILE, and 
Symbolics’ NFILE. 

The generic file model has been fairly successful, with 
very little tendency for users to bypass the generic 
interface and access a file system directly. A few 
additional file system types and file access path types 
have been added by power users. Performance does not 
seem to be limited by genericness [11]. The main failing 
is that the model doesn't include advanced features found 
in some file systems, for example record locking. 
Extending the generic file model is more difficult than 
necessary, since its internal protocols are not documented 
anywhere. 


Exceptions 


File-processing applications must cope with many 
exceptions: everything from file-not-found to disk-full to 
network problems. A robust application requires the 
system to detect and report all exceptions reliably. 
Furthermore the application must recover from 
exceptions and continue processing whenever that is 
possible. In a networked file system, many temporary 
exceptions can occur; terminating the application is not 
an appropriate response. 

In the generic file model, the possible exceptions and 
ways of reporting them vary enormously between file 
systems and between file access protocols. Thus it is 
important to provide generic exceptions in addition to 
generic operations. Some applications need to deal with 
exceptions in a very general way, while others know 
specific ways to recover from specific exceptions. This 
need for hierarchical classification of exceptions suggests 
the use of objects. 

Genera's object-oriented exception handling 
mechanism is based on the concepts of conditions, 
signalling, handlers, proceeding, and restarting. When an 
exception occurs, a condition object is created. Its class 
depends on the type of exception and its slots contain all 
necessary information about the exception. The 
condition is then signalled. Signalling searches for an 


applicable handler and calls it, passing the condition as an 
argument. Each handler specifies to which class of 
conditions it applies. A handler is dynamically 
established and remains active while control is within the 
body of the form that established it, or within anything 
called by that body. Once a handler receives control, it 
can terminate the program, recover from the exception, or 
decline to handle the condition, which searches for the 
next outer applicable handler. 

Recovery is by proceeding or by restarting. 
Proceeding passes instructions for how to recover from 
the handler back to the program that detected the 
exception, which corrects the problem and continues 
execution. For example, one could proceed from a file 
access violation by supplying a password. Restarting 
transfers control to a named restart point; usually this 
either retries or aborts the operation that failed. 

If no handler is found, a non-serious condition is 
simply ignored. A serious condition “bombs” to a 
program that asks the condition what recovery options are 
available and displays a menu of them. The user can 
choose a recovery option or select the debugger and poke 
around. Formalizing recovery makes possible this 
automatic creation of a default user interface. 

The Common Lisp condition mechanism evolved 
from Genera's facilities and unified the concepts of 
proceeding and restarting. Further details can be found in 
(12). 

The generic file model includes a rich hierarchy of file- 
system-independent condition types, classifies the 
exceptions of each particular file system and file access 
protocol according to that hierarchy, and signals all 
exceptions back to application programs as conditions. 
There are 95 generic file condition classes, in a 6 level 
deep hierarchy, plus more than 300 subclasses specific to 
particular file servers or file access protocols. Many 
other Genera facilities besides file access also use 
conditions. 

We've learned that exception handling is vital to 
robust applications, especially in heterogeneous 
networks. Representing exceptions as objects allows for 
classification of exceptions by class inheritance; thus an 
application can establish handlers either for broad classes 
of exceptions or for very specific subclasses. Detecting 
exceptions is not enough; it is also necessary to recover 
from them. Many languages with exception handling 
facilities (Ada, C++, PL/I) have not adequately addressed 
recovery. They don't pass complete information to the 
handler. They don't allow for correcting the situation and 
continuing execution. 


Namespace 


Genera has objects that model the resources available 
in a networked environment. These are divided into 
separately-administered databases, called “namespaces,” 
that map resource names to objects. These resources 
include hosts (computers), printers, peripheral equipment 
attached to hosts, users, services available by talking a 
protocol to a host, networks, sites (physical locations), 
and namespaces themselves. Originally the schema of 
the database was also an object in each namespace, but 
this had to be abandoned due to intractable bootstrapping 
problems. 

The class of an object depends on the type of resource, 
for instance a Unix host and a Macintosh host have 
different classes. Objects have named properties that 
model properties of resources, such as host names, 
network addresses, or modem speeds. Operations on 
resources, such as opening a network connection to a 
host or sending a file to a printer, are function calls with 
objects as arguments. 

The namespace system is thus involved in file access, 
printing, use of remote peripherals such as modems and 
tape drives, and all forms of networking. The generic file 
model uses information in the namespace to go from a 
pathname to a file access path. First the host name 
portion of a pathname is looked up in the namespace to 
get a host object. Then the namespace system is queried 
to determine what protocols the host supports for file 
service. The generic file system selects the best available 
protocol and instantiates a file access path of the 
appropriate class. 

Site administrators keep the namespace database up to 
date with the real world. Genera automatically uses this 
information without any action on the part of users. 

The namespace database is an ad hoc object-oriented 
database invented for the purpose. The database is cached 
in virtual memory and in saved virtual memory images. 
These caches are automatically updated as resources are 
added, removed, or changed, with some time delay’ The 
cache in a user machine is backed up by the cache in one 
or more designated server machines. The server's cache is 
backed up by text files which are the ultimate repository 
of namespace data. Normally the text files are edited 
through a special user interface, not directly as text. 

The goal of centralized network management was 
achieved. Adding more hosts or services to the 
namespace is easy and reliable. Simple changes to 
existing resources work well. The use of generic 
protocols internally in the namespace system made it 
possible to integrate with the Internet Domain Name 
system years after the namespace system was initially 
implemented; the INTERNET namespace cache is filled 
by querying domain servers instead of consulting a text 


file. Conversely, the Genera domain server gets its 
information from the namespace instead of from a zone 
master file. 

Persistent objects such as namespace objects require 
more careful design than ordinary transient objects, 
because they are subjected to more environmental 
constraints. The database semantics and the protocols for 
Namespace objects were not fully thought-out, and the 
database was designed with little knowledge of the 
database literature. As a result, complex situations such 
as coordinated changes to multiple resources, for example 
disconnecting a printer from one host and connecting it to 
another, misbehave mysteriously. The user interface for 
site administrators doesn't help with such changes, 
because it's too low-level. Schema evolution proved to 
be very difficult, a problem when new resource properties 
are invented. Servers are also clients; they use the same 
objects as caches for both roles, which is not always 
correct. Sometimes a resource is identified by its name 
and other times it is identified by its identity as an object 
in virtual memory, which creates consistency problems. 
Database performance is poor. Most of these problems 
would have been solved if Symbolics had based the 
namespace on their Statice object-oriented database [13], 
which did not exist at the time the namespace was first 
implemented. 


Software engineering 


Genera is a mature system, in use in various forms for 
over ten years, thus significant experience exists with the 
full life-cycle. Portions of Genera vary greatly in the 
degree of maintenance headaches experienced and user 
problems reported. Some portions are relatively trouble- 
free and appear to enjoy all the claimed benefits of object- 
oriented programming. Other portions have been 
constantly plagued with compatibility and modularity 
problems. 

Why is this? The troublesome portions generally 
have poorly-documented or incomplete interfaces and have 
grown by accretion, adding new objects, methods, and 
classes as the need arose. No one claims to understand 
them fully. Users have great difficulty using or 
extending them. In contrast, the better portions appear to 
have been designed ‘“‘as a whole” and usually have 
carefully documented interfaces. They seem fully object- 
oriented, built around documented protocols and objects 
that obey those protocols, so that different program 
modules deal with each other at arm's length. It’s easy 
for users to add new objects, customize existing objects, 
and get the system to behave the way they want. 

A protocol is a “contract” between a function and its 
caller, an object and its invoker, a superclass and a 
subclass, or a signaller of a condition and a handler, 


spelling out the responsibilitics and legitimate 
expectations of each party. A protocol usually involves 
several related functions or methods, describing them 
individually as well as how they interact. 

The simplest kind of protocol specifies the types of 
arguments and results, but this doesn't go very far 
towards assuring program correctness. More powerful 
protocols deal with creation of side-effects, vulnerability 
to side-effects, object states before and after calling a 
function, the required order of operations, and invariants. 
Superclass/subclass protocols also address object 
initialization, methods that a subclass must define, and 
rules about overriding inherited methods. 

A contract can be formal or informal. In Genera most 
protocols are informal and not machine-checkable, a 
matter for English-language documentation. Fully 
machine-checkable protocols would be great, but advances 
in program verification technology are necessary first. 
The Genera development environment understands a few 
aspects of protocols: It knows names of arguments and 
results, which can provide informal hints about their type 
or meaning. An abstract class can specify methods that 
each concrete subclass must define. Subclass and 
superclass methods can be combined automatically, as 
specified by the superclass. 

Protocols guide extension of the system by users and 
changes to the system by maintainers. Like “program 
logic manuals,” they can aid program understanding. As 
a system evolves and must be changed upward- 
compatibly, protocols give maintainers an idea of which 
aspects of the system's present behavior are visible to 
user programs and thus should not be changed. Protocols 
point towards replacing debugging with zero-defect 
programming. 

When requirements evolve, protocols must evolve too. 
The alternative is just to patch the implementation to 
respond to the new requirements and let the protocols 
become out-of-date; this is expedient but will create 
problems later. 

Each project to port Genera to new hardware was much 
more expensive and took much longer than anticipated at 
the start. Is this because the oft-repeated claim that 
object-oriented programming enhances portability is a 
lie? I think the answer is threefold: Modularity enhances 
portability, but the mere use of object-oriented 
programming does not automatically create modularity. 
Indeed, by enhancing productivity (i.e. minimizing the 
time to produce a working prototype), object-oriented 
programming and other techniques that speed up the 
whole process of software engineering can actually impair 
modularity, by eliminating valuable thinking time. Of 
course, inefficient methodologies can also eliminate 
thinking time, by slowing down the process so much 
that engineers are always working in crisis mode. Either 


way, time must be explicitly set aside for designing-in 
modularity. Second, many of the lowest-level, most 
hardware-dependent parts of Genera were not implemented 
in an object-oriented style, for performance reasons. The 
object mechanisms were initially very slow and were 
only made efficient after the overall structure of the 
system had been established. Third, due to loose 
management, porting projects often turned into 
reimplementation projects. The reimplementation was 
often valuable, but it's wrong to evaluate the overall 
project as if porting was all that it accomplished. 

Object-oriented methodology is no substitute for 
design. A large system can devolve into chaos if objects 
have ad hoc behavior, rather than being organized by 
protocols. It's important to keep clear in one’s head the 
difference between abstract classes (which indicate 
adherence to protocols) and concrete classes (which 
specify implementation of structure and behavior). It's a 
pity that most current object-oriented languages do not 
have these concepts within the language. They relegate 
abstract classes and protocols to documentation, which 
often tends to be neglected. Protocols should be an 
explicit part of the design and should be enforced or 
checked as part of quality assurance. The design of 
Genera paid only sporadic attention to protocols and 
suffered for it, especially in later years as the system 
grew, became more complicated, and endured 
maintenance, 


Conclusions 


The Genera experience suggests that object-oriented 
operating systems can be successful, flexible for rapid 
prototyping, adaptable in heterogenous environments, and 
efficient, However the object-oriented approach carries a 
substantial risk of under-design. The penalty later in a 
system's life can be severe if insufficient attention is paid 
to explicit protocols, accurate documentation, and 
“global” design of the system as a whole. It is also 
unwise to pay attention only to objects and their 
invocation; exception handling is a vital issue and so is 
storage management, including persistent objects. 
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